A database can store data of many different types. For example, a database may store strings, such as strings of characters representing words, as well as integers, such as the number 876. A number of other standard data types exist.
Data types may also be more complex. For example, imagine a useful data type for describing circles. Such a data type might include a graphical location for a circle center, for example, an x-y coordinate value, and a radius length in centimeters. Extrapolating from this example, one can imagine an infinite number of potentially useful data types. There can be data types for describing shapes of any kind, buildings, cars, roads, weather patterns, songs, and so forth.
A data type may correspond to an object that provides a particular function. An object is a self-contained functional unit of software. For example, an object may draw circles. Any computer program may call the circle-drawing object and request it to draw a particular circle. The circle-drawing object may require data that is stored as a particular data type, such as the type described above. Once the object is given an instance of data of the proper type, it can draw the circle.
Unconventional data types are increasingly supported by major database server software vendors. As a result, the traditional relational model for storing data in databases has been increasingly supplemented by object-relational data storage features that support user defined and/or otherwise unconventional data types. It has also become much more common to use object-oriented-based technologies in the presentation-tier and middle-tier.
Database application programming interfaces (APIs), unfortunately, have not kept pace with the increased flexibility in data storage. An application programming interface (“API”) is a computer process or mechanism that allows other processes to work together. A database API allows processes to make calls to a database to invoke database services. The API is thus a group of functional services. The actual code behind an API is located in a collection of dynamic link libraries (“DLLs”).
Present data-access APIs deal with closed type systems, and as such cannot support newly formulated data types. All data types supported by the back-end are statically known at the time the API is designed. Thus, there is a mismatch between databases that are capable of flexible storage of newly formulated data types on behalf of object-oriented technologies, and database APIs that cannot effectively recognize and support such new data types. Non-native data types may be, for example, user-defined types (UDTs) as they are described in U.S. patent application Ser. No. 10/775,282.
Modern database software such as MICROSOFT SQL SERVER®, IBM DB2®, ORACLE DATABASE®, and SYBASE IQ® provide APIs. The vast majority of enterprise applications today use databases, and therefore also use the APIs that allow applications to access and manipulate those databases. It is desirable to provide these applications, whether client-side, middle-tier, or server-side applications, with the most responsive and scalable database API possible. This is especially true for data access-intensive applications.
In light of the forgoing deficiencies, there is an unaddressed need in the industry to provide an improved database API, in particular, one that can support non-native data types.